This invention is generally directed at distributed service architectures, and more specifically at an application control and sharing architecture involving two or more users.
Distributed services are software components residing on different hardware platforms but whose distribution is transparent to the user, i.e., the various components and hardware appear to a user as one system. One way in which multiple users can receive the benefit of distributed services from each other is through the so-called sharing of an application that is running on each user's machine. Although described as sharing, a separate copy of the application is actually running on each machine. Such a scheme is also known as remote application control and is becoming an important aspect of video conferencing and other techniques for conducting meetings through computers linked to each other.
An application sharing session begins typically with a user launching an application such as a graphical presentation software package. The first user notifies other users of the beginning of the session, either by telephone or otherwise, and after which the other users also launch the same application on each of their own machines. Alternatively, a mechanism may be provided to allow the first user to launch the application in all other user machines. Several files may then be exchanged among the users to bring each user up to date. In most cases, a copy of all data used by the application is stored and cached on each machine.
When a user makes a change to an existing document or creates a new document on his or her machine, the modified document should appear on all of the other user machines in the session. Thus, if a user were to suggest a new color or shape for a particular object in a figure being viewed by all of the users, the first user would like to have this change reflected as quickly as possible in all of the other user machines.
In some prior art application sharing schemes, the entire document as modified by a user is packaged as a whole and sent off to the other users. Because the modified document may include graphics and even audio information as well as simple text, a large amount of information will need to be communicated between the users. If the session includes user machines that connect via telephone lines, however, then well-known communication bandwidth constraints may prevent the speedy transfer of such rich documents between the users. Since the communication bottleneck is the limited rate at which information can travel through the telephone lines, a low bandwidth application sharing architecture that generates the least amount of data for transfer among the users is needed.
Another desirable feature in an application sharing session would be to operate in a multicast environment. In such an environment, the application sharing scheme must allow a user, together with her shared application running on her machine, to support a number of connections to a number of other users who are part of the application sharing session, without her application having to know the exact identity and network address of the other users. Finally, such an optimal application sharing architecture should be implemented so as to operate, with minimal additional modifications, on a number of different computing platforms. These platforms may include different hardware as well as different operating systems.
Several attempts at meeting the above described challenges have been made. For example, in the protocol specification T120 relating to multipoint data communication, command packets are sent to another user at a remote location for handling by the application at the remote location in a hierarchical group routing scheme. A draw back of this technique is limited performance, since the hierarchical group topology requires the routing of packets through multiple intermediate endpoints rather than directly to each destination group member. Each intermediate endpoint must forward the packets to zero or more destination leaf nodes. Each leaf node in turn may have a number of child nodes attached to itself, such that arrival of a command packet at a final destination group member is delayed.
Another potential solution to the application sharing problem would be to use a request/response protocol such as the Remote Procedure Call (RPC) based on standards defined in the Distributed Computing Environment created by the Open Software Foundation. With RPC, it is possible to write a program on a first machine that calls a subprogram implemented on a second machine. In such a request/response protocol, the first user sends a request message to designated users, the message containing controls and commands as well as perhaps data, and expects a response acknowledging receipt of the message.
The problem, however, with using RPC is the well-known "acknowledge explosion" in which a response acknowledging the receipt of the message is sent by all those who receive the message. In a request/response protocol, all users who receive the request must send a response back to the originating user or else the message packet is resent to enforce reliability. Therefore, if the application sharing session is to proceed using RPC in a multicast environment where the first user in effect broadcasts its messages to all other users in the session, then an additional mechanism must be provided for the user to handle the acknowledge responses that will be coming in from all of the other users.
To avoid the acknowledge explosion described above, a NACK (negative acknowledgment) protocol may be used wherein the first user presumes its message has been received, unless otherwise indicated. Protocol specifications have been developed and implemented which use this technique successfully to deliver the required 100% delivery guarantees.
Yet another technique for creating an application sharing architecture is based on the Object Linking and Embedding (OLE) environment developed by Microsoft Corp. OLE is a unified environment of object-based services with the capability of both customizing those services and arbitrarily extending the architecture through custom services, with the overall purpose of enabling integration between components. OLE allows an application to define an interface which other applications can connect to control the application, under the title Automation. But OLE Automation is limited to local applications running on the same machine. Problems with migrating the RPC protocol to OLE Automation include the above described acknowledge explosion.
Finally, a technique exists to intercept application function calls to the operating system and to transmit each such call to all nodes in the application sharing session. Some problems with such a technique are the use of undocumented and unsupported subsystem data structures, and the platform dependence of the implementation. This technique was feasible in the 16-bit Microsoft Windows operating system, but is not directly supported by more advanced 32-bit operating systems. Protection subsystems of more advanced operating systems such as Microsoft Windows 95 and Windows NT do not easily allow such intrusive techniques to be implemented. So, although such a scheme might be possible, it requires programming in kernal space (Ring 0), deep within the confines of the operating system. Furthermore, such a solution is operating system dependent, a serious product marketing drawback.